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(54) Fraud detection method for mobile telecommunication networics 



(57) The present invention provides a fraud detec- 
tion metliod for third generation nnoblle telecommunica- 
tion systems using data related with unsuccessful au- 
thentication procedures, such us access type, authen- 
tication re-attempt and server address as secondary 
fraud indicators. Said data are included In predefined- 



type fields of the authentication failure report message 
sent from the Serving Environment bacl< to the Home 
Environment in said authentication procedures, stored 
in the Home Location Register and forwarded to the 
Fraud Detection Systems for processing in conjunction 
with primary fraud indicators, for fraud detection purpos- 
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Description 

Field of the Invention 

[0001] This invention relates generally to the fraud de- s 
tection in mobile telecommunication networks. More 
specifically, this invention relates to a method for obtain- 
ing, storing and processing significant data for fraud de- 
tection. 

10 

Background 

[0002] The security group in the 3^ Generation Part- 
nership Project, in chiarge of Security Architecture (here- 
inafter refen-ed to to as "3GPP (SA3)"), have introduced is 
in the Technical Specification Group Services and Sys- 
tem Aspects 33.102 V3.5.0 (hereinafter referred to as 
3G TS 33.102) a new procedure called Authentication 
Failure Report. Besides, the standard signalling mes- 
sages and message parameters involved in said new 
procedure are described in the Mobile Application Part 
(hereinafter referred to as MAP) specification 29.002 
V3.4.0 Issued by the 3GPP Technical Specification 
Group Gore Network (hereinafter said specification is 
refen-ed to as 3GPP TS 29.002). 25 
[0003] Most of the previous generations of mobile 
systems already make use to some extent of Authenti- 
cation procedures to ensure that a user accessing the 
mobile network is the one who claims. And not only the 
mobile users but rather the different network entities In- 30 
voived in certain mobile communications are already 
objects of authentication to some extent. Any interested 
reader can refer to Technical Specification 03.20 for 
GSM "Security related network functions" from the Eu- 
ropean Telecommunbation Standard Institute (general- 35 
ly known and hereinafter referred to as TS ETSI GSM 
03.20, "Security related network functions"). These au- 
thentbatlon mechanisms are intended to preclude the 
access to the mobile networks and mobile services for 
unauthorised users or network entitles. Moreover, the 40 
needs for authentication of mobile users and network 
entities do not only make sense for the Pan-European 
mobile networks like GSM, but also for the Pan-Ameri- 
can mobile networks lil<e those based on the Interim 
Specification number 41 (hereinafter referred to as IS- ^5 
41), for example. 

[0004] These authentication mechanisms from previ- 
ous generations of mobile systems are naturally evolv- 
ing, including new security features, within the scope of 
the 3^** mobile systems generation (hereinafter simply so 
referred to as 3G). Nowadays, a well-known instance of 
3G is the Universal Mobile Telecommunication System 
(hereinafter referred to as UMTS) and security aspects, 
security features and security architecture, such as 
those related to subscriber Authentication and network ss 
entity Authentication, are described in the technical 
specification above mentioned, 3G TS 33.102. 
[0005] Irrespective of particular networic architectures 



that these mobile systems generations might have, in- 
cluding different standards such as the Pan-European 
or Pan-American standards above mentioned, some 
commonalties are pointed out following this to better un- 
derstand the wider scope of the present Invention. 
[0006] On the one hand, any mobile network like the 
one in Fig.-1- can be regarded as consisting of a Home 
Environment (N-1000) (hereinafter referred to as HE), 
a Serving Network (N-2000) (hereinafter referred to as 
SN), and a number of mobile terminals, namely User 
Equipment (N-3000) (hereinafter abbreviated as UE). 
On the other hand, such a mobile networic In Fig.-I • can 
be regarded as consisting of a Core Network (N-0100) 
and an Access Network (N-2200) wherein the former 
consists of the Home Environment plus the Serving Net- 
work excluding networic entitles from the Access Net- 
work. 

[0007] Furthemnore, the existing mobile systems al- 
ready offer support with shared and dedicated network 
infrastructure for both Circuit Switched (N-2120) (here- 
inafter CS) sen/ices, such as pure telephony, as well as 
Packet Switched (N-2110) (hereinafter PS) services, 
such as other data transmission oriented services. The 
packet switched services have been lately introduced 
over the 2G mobile systems. A well-known instance of 
the existing technology to support the packet switched 
services is the GSM Packet Radio System (hereinafter 
abbreviated as GPRS). 

[0008] The HE (N-1000) represents all the networi< 
entities which uniquely handle and give support to home 
subscribers of a certain Public Land Mobile Networi< 
(hereinafter PLMN). For example, the Home Location 
Register (N-1102) (hereinafter HLR) is the networi< en- 
tity of a certain PLMN in charge of holding all the sub- 
scription data for home subscribers of said PLMN, and 
thus part of the HE. Another network entity also part of 
the HE is the Authentication Centre (N-1101) (hereinaf- 
ter AUC), which Is In charge of generating and providing 
authentication and key data either as triplets for GSM 
or as vectors for UMTS. These authentication and key 
data are respectively intended to check that any home 
subscriber is the one who claims, wherever he or she is 
accessing the mobile network, and to provide the means 
for ciphering the transmission through the radio path. A 
more detailed explanation of usage and procedures for 
2G and 3G Authentication Is further Introduced In this 
description. 

[0009] The SN (N-2000) represents all the networi< 
entities or resources in a certain PLMN that give service 
to mobile subscribers roaming in such a PLMN irrespec- 
tive of being home or visitor subscribers. For example, 
the Mobile Service Switching Centre (also called Mobile 
Switching Centre, and hereinafter abbreviated as MSC) 
constitutes the interface between the radio system and 
the fixed networks. Said MSC is the network entity in 
charge of all switching functions related to Circuit 
Switching (CS), controlling the location and routing area 
wherein a certain subscriber is roaming, and thus part 
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of the SN. Another network entity part of the SN is the 
Visitor Location Register (hereinafter abbreviated as 
VLR). Said VLR is a subscriber database holding rele- 
vant subscription data from all the subscribers currently 
roaming in the area controlled by such a VLR, and which 
were obtained from the corresponding HLR where each 
subscriber has his or her own subscription. At present, 
most of the existing GSI\/I or IS-41 based mobile sys- 
tems have implemented both entitles collocated so that 
they are usually refen^ed to as a unique entity (N-2121) 
by the abbreviation MSCA/LR. Furthemnore, the 
evolved version of said IVISC/VLR for the 3Q mobile sys- 
tems is generally referred to as 3G MSC/VLR. In a sim- 
ilar manner as said MSC/VLR is in charge of relevant 
subscription data, and carries out the CS functions, the 
Serving GPRS Support Node (N-2111) (hereinafter ab- 
breviated as SGSN) performs similar tasks for PS func- 
tions and corresponding subscribers. The SGSN holds 
relevant subscription data from all the subscribers cur- 
rently roaming in the area controlled by such an SGSN, 
and which were obtained from the corresponding HLR 
where each subscriber has his or her own subscription. 
Said SGSN is also in charge of all switching functions 
related to Paclcet Switching (PS) , controlling the location 
and routing area wherein a certain subscriber is roam- 
ing, and thus part of the SN. Furthermore, the evolved 
version of said SGSN for the 3G mobile systems is gen- 
erally referred to as 3G SGSN. Besides, Fig.-1- also 
shows a representative access network node for com- 
pleteness purpose, namely the UMTS Terrestrial Radio 
Access Network (N2201) (hereinafter referred to as 
UTRAN). 

[0010] The authentication procedure, generally 
speaking, is initially performed at the first radio contact 
from a mobile subscriber trying to gain access to the mo- 
bile network. In accordance with the specification 3G TS 
33.102 above mentioned, the method was chosen In 
such a way as to achieve maximum compatibility with 
the cun-ent GSM security architecture and facilitate mi- 
gration from GSM to UMTS. The method is composed 
of a challenge/response protocol identical to the GSM 
subscriber authentication and key establishment proto- 
col combined with a sequence number-based one-pass 
protocol for network authentication. Even though this 
procedure is basically described following this, an inter- 
ested reader could get more detailed explanations by 
reading said specification 3G TS 33.102 version 3.5.0, 
sections 5.1 .1 and 6.3.1 . 

[0011] The challenge/response method from GSM 
fomially starts by a request from the SN VLR/SGSN to 
the HE HLR/AUC to generate and provide authentica- 
tion triplets (authentication vectors under 3G). Said au- 
thenttoation triplet consists of a random number RAND, 
an expected response XRES, and a ciphering Key CK. 
Each authentication triplet Is valid, in principle, for just 
one authentication process, though they can be reused 
undercertain circumstances. At reception of said triplets 
from the HE, the VLR/SGSN sends to the GSM Sub- 



scriber Identity Module (hereinafter abbreviated as 
SIM), which Is responsible for perfomiing GSM sub- 
scriber authentication and key agreement at the sub- 
scriber side, the received random number RAND. At the 
s subscriber side, the ?W4D and a pre-stored subscriber 
identity key Kl are used as inputs to algorithms A3 and 
A8 to produce a signed response S RES and a ciphering 
key CK. The SIM returns the SRES obtained to the chal- 
lenger VLR/SGSN, which will check the lately received 

10 SRES versus the stored XRES. Provided that they 
match each other, the authentication is found to be suc- 
cessful and the CK, that both VLR/SGSN and SIM have, 
can be locally used to cipher further communication 
through the radio path. 

IS [0012] Fig.-2- schematically presents how this chal- 
lenge/response authentication method evolves for 
UMTS networks. In accordance with 3G TS 33.1 02, the 
HE HLR/AUC is requested (S-200) to generate and pro- 
vide authentication vectors consisting of a random 

20 number RAND, an expected user response XRES, a ci- 
pher key CK, an integrity key IK, and a network authen- 
tication token AUTN. Upon receipt of such a request 
from the SN VLR/SGSN, the HE HLR/AUC generates 
(B-090) and sends an ordered an-ay of n Authentication 

25 Vectors (S-210) (the equivalent of GSM "triplets", and 
hereinafter referred to as AV) to the SN VLR/SGSN 
wherein these authentication vectors are stored (8- 
100). As for GSM, each authentication vector is valid for 
one authentication and key agreement process be- 

30 tween the VLR/SGSN and the User Services Identity 
Module (hereinafter referred to as USIM). As opposite 
to GSM, these vectors cannot be reused. In a security 
context, such a USIM is responsible for perfomning 
UMTS subscriber and network authentication, and key 

3s agreement. Said USIM should also be capable of per- 
forming GSM authentication and key agreement to en- 
able the subscriber to roam easily into a GSM Radio Ac- 
cess Network. When the VLR/SGSN initiates an authen- 
tication and key agreement, it selects the next authen- 

^0 tication vector from the array (8-1 1 0) and sends the pa- 
rameters RAND and AUTN to the user (S-220). The 
USIM checks whether AUTN can be accepted by com- 
puting the anonymity key AK as a function of RAND (8- 
1 20) and then, once AK is known, by extracting from the 

45 received AUTN the sequence number SQN (8-1 30), the 
authentication management field AMF (8-1 40), and the 
message authentication code MAC (B-150). Next USIM 
computes XMAC as a function of RAND, SQN, and AMF 
(8-160) and compares such an XMAC value with the 

50 previously extracted MAC (8-1 70). Provided that these 
values are found to be different, the user sends a "user 
authentication reject" (S-230) back to the VLR/SGSN . 
with an indication of the cause, and the procedure is 
abandoned. This result is understood as an unsuccess- 

55 ful network authentication. In thiscase, the SN VLR/SG- 
SN shall Initiate an Authentication Failure Report (S- 
240) towards the HE HLR Indicating "wrong network sig- 
nature" as failure cause. On the other hand, when MAC 
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and XMAC match each other, USIM verifies that SON 
value is in the correct range (B-1 80). Provided that USiM 
considers SQN is not in due range, it sends a "synchro- 
nisation failure" {S'250) back to the VLR/SGSN Includ- 
ing an appropriate parameter, and the procedure Is s 
abandoned. If SQN is in range, USIIVI considers the net- 
work as successfully authenticated and computes a re- 
sponse RES, a cipher key CK and an Integrity key IK by 
applying different functions to different combinations of 
authentication parameters (B-1 90). Said response RES io 
Is sent back to the VLR/SGSN {S-260). The VLR/SGSN 
compares the received RES with XRES (B-200). If said 
RES and XRES match each other the VLR/SGSN con- 
siders the authentication and key agreement exchange 
to be successfully completed. The established keys, CK 
and IK, will be locally used to cipher further communi- 
cation through the radio path. But, if XRES and RES are 
found to be different, the SN VLR/SGSN shall Initiate an 
Authentication Failure Report (S-270) procedure to- 
wards the HLR indicating "wrong user response" as fail- 20 
ure cause. Moreover, the SN VLR/SGSN may also de- 
cide to re-attempt a new Identlfbatlon and authentica- 
tion procedure towards the user 
[0013] In accordance with the 3G TS 33.102, this 
mechanism somewhat described above achieves mu- 25 
tual authentication by the user and by the network, 
showing knowledge of a secret key K which Is shared 
between and available only to the USIM and the AUG In 
the user's HE. Moreover, a network authentication fail- 
ure detected at the user side, namelyby USIM, ora user .30 
authentication failure detected at the network side, 
namely by SN VLR/SGSN, they both trigger the new 
procedure "Authentication Failure Report". 
[0014] The aim of this new procedure is to inform the 
Home Environment (HE) when an authentication has 35 
failed, including the failures due to an unsuccessful net- 
work authentication or unsuccessful user authentica- 
tion. However, this procedure Is not applicable to syn- 
chronisation failures, which are reported by a different 
procedure. In summary, such an Authentication Failure 
Report procedure is merely used to report the kind of 
failure (user or network) and the International Mobile 
Subscriber Identity (hereinafter referred to as IMS!) to- 
wards the HE. 

[0015] At this point, another significant aspect to com- 
ment on, background of the present invention, is the 
fraudulent use of mobile services and mobile networks. 
One of the highest fraud exposures in mobile networks 
is due to call selling using supplementary services, and 
especially due to the difficult control of subscriber activ- so 
Ities when said subscribers are roaming In a PLMN other 
than the home network. In this context, Call Selling is a 
fraudulent activity that consists in using a mobile sub- 
scription to sell long distance calling service throughout 
the worid, below market price, and with the Intention of ss 
not paying for such calls to the network operator. For 
example, a mobile subscriber may initiate fraudulent call 
selling by making use of Call-Forwarding service In HLR 



and Third-Party call service. Still another example of 
fraud is the Roaming Fraud. As a matter of fact. Inter- 
national roaming is possible for most of mobile systems 
wherein the fraud Is carried out by Initiating call selling 
operations by using foreigners subscriptions In certain 
countries where roaming is possible. This fraudulent ac- 
tivity can hardly be detected on time to act because of 
late reporting and billing from the operators Involved. 
These and many other fraud risks have been identified 
and justify the efforts to provide the means to prevent 
fraud, and also to detect the specific fraudulent activity. 
In this respect, most of the mechanisms introduced 
around the authentication procedures are more oriented 
to fraud prevention than to the fraud detection as such. 
[0016] Nevertheless, and assuming that said fraud 
prevention Is not always achieved, great efforts are 
made to develop fraud detection systems robust enough 
to ensure a rapid detection of fraudulent activities. An 
important aspect to detemnlne is the criteria to unambig- 
uously identify that a fraud Is committed. Rather than 
focusing on legal frames to detemnlne fraud, this de- 
scription is aimed to outline activities and situations 
which, isolated or combined, can Indicate a fraudulent 
use of mobile network resources. 
[0017] To this end, a new networic entity generally 
known as Fraud Detection System (hereinafter refen^ed 
to as FDS) was introduced In mobile networtcs. Said 
FDS is responsible for detecting the existence of fraud 
by analysing a certain arnount of indicators. Such indi- 
cators are classified attending to type and way of use. 
As classifying indicators by type, the following three cat- 
egories can be Identified: 

i) Usage indicators are defined by some criteria re- 
lating to the way in which a mobile telephone is 
used. Most types of fraud are characterised by un- 
usually high usage. For example in call selling ac- 
tivities, the mobile tennlnal needs to register several 
call-forwarding numbers. 

ii) Mobiiity indicators are defined by some criteria 
relating to the mobility of mobile user. For example 
number of location updating or hand-over during a 
defined time Interval. 

ill) Deductive indicators that arise as a result of a 
fraudulent behaviour: For example, use of confer- 
ence calls, forwarded calls, etc. 

[001 8] As classifying indicators by way of use, the fol- 
lowing three categories can be identified: 

i) Primary Indicators, which in principle, can be em- 
ployed in Isolation to detect fraud. For example, the 
number of call-fonA/ardIng services Invoked within a 
defined time Interval. 

ii) Secondary indicators from which, in principle, 
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useful Information can be gained if they are consid- 
ered in Isolation, but which should not be solely 
used to detect fraud. For example, jnfonnatlon 
about cell sites or switch areas Involved in a certain 
call handling, since Call-selling for certain destina- s 
tions Is concentrated in areas where the buyers live. 

Ill) Tertiary indicators from which no useful Infomna- 
tion can be gained if they are considered in isola- 
tion, but which can, in principle, be used to provide io 
essential intomfiation in connection with the detec- 
tion of fraud. For example, the number of successful 
hand-over within a defined time Interval. In this re- 
spect, a fraudulent call-selling service requires a 
stable position so that a low mobility, accompanied 
by other activities with corresponding indicators, 
nilght identify possible fraudulent activities. Obvi- 
ously, many mobile users may have this low mobility 
behaviour without perfomning any fraud so further 
detection of other activities Is essential before being 20 
able to determine fraud. 

[0019] Such an FDS is supposed to post-process 
these indicators to determine whether a fraudulent ac- 
tivity is occurring or, at least, suspicious of occurring. 25 
[0020] These two main, separate, and not connected 
aspects hereinabove commented on, that is the actions 
performed on authentication failure and the needs for 
fraud detection, are both background of the present In- 
vention as further justified in this description. 30 
[0021] The Authentication procedure has been com- 
mented on for both 2G and 3G mobile networl<s. A new 
procedure, "Authentication Failure Report", has been in- 
troduced for 3G mobile systems like UMTS, however, 
no con*esponding procedure exists for some 2G system 35 
like GSM. 

[0022] Nevertheless, specific vendor additions are 
provided to enhance and complete the current stand- 
ards for 2G mobile systems. For Instance when an au- 
thentication failure is detected In an Ericsson provided 40 
MSC/VLR, said MSC/VLR logs all the relevant failure 
data, and activates an alarm. Said logging of authenti- 
cation failure includes data such as date, time, IMSI, Mo- 
bile Subscriber ISDN number (hereinafter referred to as 
MSISDN, wherein ISDN stands for Integrated Services 45 
Digital Network), Cell Global Identjfier(hereinafterCGI), 
and whether the MAP message "Authentication Rejecr 
was sent or not. 

[0023] These vendor solutions Imply that In a multi- 
vendor and multi-operator environment it is not now pos- 50 
sibie to gather all the fraud related infomiation regarding 
authentication failures for a single subscriber. Such an 
information would be stored in MSC/VLR from certain 
vendors whereas others will collect other authentication 
failure data along the different serving networi<s. Under ss 
these assumptions, such a solution cannot be taken as 
a basis for introducing a standard fraud detection sys- 
tem given that an MSC/VLR vendor identifier should al- 



ways be used as Initial fraud criterion to analyse. Then, 
depending on the specific MSC/VLR vendor, other avail- 
able authentication failure data could be used for post- 
processing at the FDS. 

[0024] Regarding fraud detection, other solutions ex- 
ist in 2G mobile systems and have been adopted by dif- 
ferent suppliers to some extent. One of the most com- 
mon architecture to support fraud detection in mobile 
networks is illustrated in Fig. -3- where the FDS (N-1 301 ) 
gathers the indicators required to perform the fraud 
analysis from the Call Data Records (hereinafter re- 
ferred to as CDR) generated in the MSC/VLR (N-2122) 
or the SGSN (N-2112). Said CDRs are submitted 
through the Billing Gateway (N-2301) (hereinafter re- 
ferred to as BGW), or any other Billing Mediation Device. 
As a consequence, the information received by the FDS 
is just related with the establishment of a call, whereas 
any other fraud related Information, not call related, 
does not reach the FDS. This Infomnation is not received 
by the FDS by current means since it is not related with 
a call already established, and therefore there cannot 
be any CDR associated. For instance, fraud related in- 
fonmation derived from an authentication failure does 
not imply any CDR to be received at the FDS under this 
solution. The case of call selling already commented on 
would have likely originated a CDR submitted In the 
past, whereas subsequent attempts to Initiate such a 
call selling would get unsuccessful authentication re- 
sults. In this respect, the fraud prevention is achieved, 
however, anyone skilled in the art can easily understand 
that fraud detection would be even worthwhile in order 
to know when new attempts to commit fraud are initiat- 
ed. 

[0025] On the other hand, and unlike 2G systems like 
GSM, there Is an Authentication Failure Report proce- 
dure for IS-41 (TIA/EIA standards). Under said proce- 
dure, the report message is used by the Authentication 
Centre in IS-41 (hereinafter referred to as AC, unlike the 
one in GSM) in order to decide whether the access for 
that subscriber will be denied, or a different action relat- 
ed with the standard security procedure Is required. 
Nevertheless, no specific activity related with fraud de- 
tection is considered. 

[0026] The Authentication procedure in tS-41 is not 
always performed in the same way. On the one hand, 
the VLR might have a Shared Secret Data (hereinafter 
referred to as SSD) that the AC had previously sent, so 
that the authentication data to be used in the authenti- 
cation procedure are obtained from said SSD. On the 
other hand, the VLR might receive the authentication 
data directly from the AC, in a similar way as is done for 
GSM, In order to use them in the authentication proce- 
dure. Whateverthe case, when an authentication failure 
occurs (the response sent by the user does not match 
the expected response hold by the VLR) the VLR does 
not make any decision but sends said authentication 
failure report to the AC. The AC then decides whether 
the access is denied or a new authentication must be 
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performed. For the latter, the AC also decides if new 
SSD is sent to the VLR, for said VLR to generate new 
authentication data, or if new authentication data are di- 
rectly generated by the AC and sent to the VLR to be 
directly used In the new authentication procedure. What ^ 
this procedure achieves is a centralised decision mech- 
anism to control the network. 
[0027] At present, there Is a new procedure Intro- 
duced for UMTS, the "Authentication Failure Report" 
procedure already commented on above, which is io 
merely intended, to allow a centralised storage in the 
Home Environment (HE) for authentication failure data. 
With such a mechanism the HE can just control whether 
home subscribers are suffering or producing authenti- 
cation failures. is 
[0028] However, the presently specified Authentica- 
tion Failure Report procedure does not offer valuable 
infonnation yet from a fraud detection perspective to 
take further actions. In this respect, Flg.-4- shows the 
existing operation Authentication_Failure_Report as 20 
specified in 3G TS 29.002 for the Mobile Application Part 
protocol, in terms of Operation and Parameters. 
[0029] Still another drawback, from the current solu- 
tions fraud detection related, is that the CDR only exist 
when there Is a call already established, whereas noth- 25 
Ing can be detected with this solution as the fraudulent 
user equipment Is trying to gain access to the network. 



Summary of the Invention 



30 



[0030] The object of the present invention is a method 
for providing relevant infomriation for fraud detection 
which overcomes the above mentioned drawbacks. 
[0031 ] In accordance with the present invention, data 
related with unsuccessful authentication procedures, 3S 
such us access type, authentication reattempt and serv- 
er address, could be used for fraud detection. 
[0032] The method gets advantage from the new In- 
troduced mechanism to report authentication failures in 
order to provide more valuable infomnation from a fraud 40 
detection perspective towards the Home Environment, 
including the steps of: 

a) obtaining secondary fraud Indicators from fail- 
ures in user authentication procedures due to un- 
successful network authentications or unsuccessful 
user authentrcations 

b) including said secondary fraud indicators as new 
parameters of specific types In fields of the Authen- 
tication Failure Report message (hereinafter re- so 
ferred to as MAP AFR_req) sent from the Serving 
Environment {3G MSCA/LR, 3G SGSN) back to the 
Home Environment (HE HLR) in said authentication 
procedures 

c) storing said messages in the Home Location ss 
Register (HLR) for further processing. 

[0033] Another object of the method of the present In- 



vention Is the forwarding of these fraud-related data col- 
lected In the Home Environment towards an appropriate 
operator specif ic device for Fraud Detection for process- 
ing in conjunction with primary fraud indicators for fraud 
detection purposes. 

Brief Description of the Drawings 

[0034] For the sake of clarity and a better understand- 
ing of the scope and objects of the present invention, 
this detailed description should be taken in conjunction 
with the accompanying drawings, in which: 

Fig.-I - is a block diagram representing a mobile tel- 
ecommunication system from a subscriber and net- 
work authentication perspective. This .system is 
structured attending to different criteria: 

• the Home Environment where the subscription 
resides versus the Serving Network where the 
subscriber is roaming; 

• the Core Network versus the Access Networic 
and the User Equipment; 

• the Circuit Switching services versus the Pack- 
et Switched services and corresponding net- 
work support. 

Flg.-2- Is a flow chart schematically representing 
the authentication procedure as currently specified 
for 3G mobile systems like UMTS networks. 

Fig. -3- is another block diagram representing a cur- 
rently existing fraud detection system for call related 
fraudulent activities 

Flg.-4- shows the prior art MAP operation 
Authentication_FaHure_Report, as described by 3G 
TS 29.002 recommendations for UMTS, in temris of 
Operation and Parameters. 

Fig.-5- is the block diagram representing the archi- 
tecture required for a complete fraud detection sys- 
tem accordingly with the present Invention. 

Fig.-6- is a flow chart schematically representing 
the authentication procedure for 3G mobile systems 
like UMTS networks In accordance with the present 
Invention. 

Flg.-7- presents the new MAP operation 
Authentication_Failure_Report in terms of Opera- 
tion and Parameters in accordance with a preferred 
embodiment of the present invention. 

Flg.-8- is another flow chart schematically repre- 
senting the sending of the MAP operation 
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Authentication_Fallure.Report with new proposed 
data, in accordance to the present invention, stor- 
age of said data in the H LR and further transmission 
of such data towards the FDS for fraud analysis. 

5 

Detailed Description of Preferred Embodiments 

[0035] There Is very valuable Infomnation for fraud de- 
tection behind an authentication failure as explained 
hereinabove. The data related with authentication fail- io 
ure can never be used as primary indicator to detect 
fraud, since authentication is itself a method for fraud 
prevention, but said data can be used as secondary in- 
dicators so that further actions can be taken. However, 
the data sent in the UMTS Authentication Failure Report is 
message are quite poor, from a fraud-detection point of 
view. Just the IMSI and the kind of failure are reported 
within such a ly/lAP operation, as primary shown in Fig.- 
2- (S-240, S-270) and further stated in Fig.-4-. 
[0036] On the other hand, there is quite valuable and 20 
significant infomnation for fraud detection in the MSG/ 
VLR, which is related or can be derived from an authen- 
tication failure. These significant data for fraud are con- 
sidered as secondary Indicators for fraud, and are part 
of fraud criteria in a Fraud Detection System. 25 
[0037] In accordance with the present invention, other 
data already known by the MSC/VLR, when the authen- 
tication procedure shown in Fig. -2- takes place, should 
also be provided to the HE HLR within the MAP mes- 
sage Authentication Failure Report request (MAP 30 
AFR_req) (S-280, S-290) as shown in Fig.-6- and Fig.- 
7-. Some of said known data, relevant for fraud detec- 
tion, are the following: 

• Access type. In order to distinguish If the authenti- 35 
. cation procedure was initiated due to a call, an 

emergency call, a location updating, a supplemen- 
tary service procedure or a short message transfer. 

• Authentication reattempt. This indicates whether 40 
the failure was produced in a nomnal authentication 
attempt or It was due to an authentication reattempt. 
The latter indicates that there was a previous un- 
successful authentication. 

45 

• Server address. It Indicates the address of the net- 
work element, either SN MSCA/LR or SN SGSN, 
where the authentication procedure took place. 
This data shall be Included in order to have a refer- 
ence to the physical location where the authentica- so 
tion failure had been produced. 

Each of the three new parameters has its own 
advantage in accordance with the present inven- 
tion. 

The access type parameter can be used to ss 
evaluate the seriousness of the failure since It can 
be considered more serious a failure produced in a 
location updating than in a call set up, and the latter 



more serious than the one produced in a short mes- 
sage transfer. These considerations are based on 
some facts; for example, a successful location up- 
dating has to be performed previous to an unsuc- 
cessful call. 

The authentication reattempt parameter is sent 
in order to know if the failure was produced on a first 
authentication procedure or during a reattempt. An 
authentication reattempt is perfonned in current 
networks since the failure could have been pro- 
voked by a Temporary Mobile Station Identity (here- 
inafter TMSI) mismatch, or by en^oneous Authenti- 
cation Vectors received from the previous MSG/ 
VLR or SGSN server (the reattempt is perfomied 
after requesting new Authentication Vectors to the 
HLR). When the authentication reattempt is per- 
fomned, the corresponding procedure is carried out 
with the correct IMSI (User Identity Request per- 
fomied) and with correct Authentication Vectors 
(Send Authentication Info perfonned), thus an error 
in this case is of higher importance. 

The interest of the server address from a fraud- 
detection point of view resides in the fact that some 
fraudulent activities like call selling in current mobile 
networics are associated with concrete geographi- 
cal location. 

These and other data not explained yet are 
Identified as being of interest for a Fraud Detection 
System (FDS) as secondary Indicators, and part of 
the fraud criteria analysis in said FDS. When new 
fraudulent activities are identified, new data will be 
found to be Interesting as fraud indicators, and still 
part of the present invention. The scope of the 
present invention Is not Intended to be restricted to 
only these three identified and explained new data, 
to be included within the existing MAP AFR_req 
message, as anyone skilled in the art may easily 
understand. For example, and as an additional em- 
bodiment of the present invention, provided that the 
severity of fraud requires more accurate information 
about the geographical position where the fraud Is 
committed, the user equipment position got by 
means of GPS facilities could also be sent in the 
MAP AFR_req message. As anyone skilled in the 
art may easily understand, known data at the MSG/ 
VLR or SGSN, which are significant for fraud detec- 
tion, can be included in the MAP AFR_req mes- 
sage. In this way, these data can be eventually sub- 
mitted to the HE HLR and from there fonwarded to 
an appropriate Fraud Detection System like the 
FDS. 

In accordance with Fig.-7-, the proposal of a 
preferred embodiment of the present invention is 
that these data, namely the Access Type, the Au- 
thentication Reattempt, and the Server Address 
should be including as new specific parameters 
within the MAP AFR_req message. Moreover, still 
under a preferred embodiment of the Invention, the 
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Server Address should be better expressed in 
terms of different paranneters such as l\^SC/ 
VLR_address and SGSN_address In order to iden- 
tify on what service, Circuit or Pacltet, the authen- 
tication has failed. 

In accordance with the message and parame- 
ters fomriat specified by 3G TS 29.002, the following 
new parameters could be Included for the existing 
MAP message "authenticationFailureReport_req" 
in said specifications, 3G TS 29.002, as Fig.-7- 
states. 

• "authentlcatjonReattempt" of type "BOOLEAN" 

• "accessType" of a new type "AccessType" 

• "vlr-Number" of type "[0] iSDN-AddressString" 

• "sgsn-Number" of type "[1 ] ISDN-AddressString" 

[0038] Furthennore, the new type above introduced 
"AccessType" could also be declared following the ASN. 
. 1 notation as "ENUI\/IERATED" with the following assig- 
nations: Gall (0), emergencyCall (1), iocationUpdating 
(2), supplementaryServices (3), shortMessage (4). As 
anyone skilled in the art can easily understand re-order- 
ing the previous assignations will not substantially affect 
the object of the present invention under this preferred 
embodiment. 

[0039] Moreover, the inclusion of these new data 
above mentioned in the MAP AFR_req operation, In ac- 
cordance with the preferred embodiment of the inven- 
tion as shown in Flg.-7-, should be understood In an il- 
lustrative and non-restrictive manner. In this respect, a 
secondary embodiment of the present invention sug- 
gests the inclusion of these new data above within the 
Extension Container field. 

[0040] The MAP AFR.req message definition allows 
the introduction of new parameters in an extension con- 
tainer. All the data proposed in the present invention, as 
fraud indicators, could be Included In the mentioned ex- 
tension container. 

[0041] Said extension container can be regarded as 
the means to introduce proprietary Information In a 
standard message and thus, provided that the fraud in- 
dicators are Included there, the result wilt be a proprie- 
tary solution to some extent. 

[0042] As already stated above, one of the main ob- 
jects of the present invention Is that any operator can 
gather all the fraud information related with authentica- 
tion faults from Its own subscribers. With a proprietary 
solution this would not be achieved since the reception 
of that Infonnation would directly depend on the VLR/ 
SGSN supplier and therefore it would indirectly depend 
on the serving operator (roaming situation for the sub- 
scriber). As a consequence, an operator could not gath- 
er all the fraud infonnation regarding authentication 
fraud from Its own subscribers. Nevertheless, though 



less efficient than the pretended embodiment, this sec- 
ond embodimerit of the present Invention also proposes 
reasonable means to provide an FDS with the required 
secondary indicators for fraud detection. 
5 [0043] A further process step of the present Invention 
is the reception of these new fraud related data, Included 
in the MAP AFR_req operation. In the HE as Fig.-8- il- 
lustrates. 

[0044] At reception of the MAP AFR_req message (S- 

10 700) the HLR will store the received data together with 
the time and date of the report (B-500). 
[0045] When the number of failures reaches a given 
threshold value (B-51 0) for a certain subscriber an alann 
shall be issued at the HLR (B-520). The value for such 

IS a threshold that triggers the alamn shall be configurable. 
[0046] Next, an "Authentication Failure Alamn" (S- 
710) will be addressed to the Operation and Mainte- 
nance Gateway (hereinafter referred to as OMG) in the 
operator network. Then, through that Gateway said Au- 

20 thentication Failure Alamri (S-720) will reach the FDS. 
[0047] On reception of such an alamn, the FDS would 
use the commands through the Operation and Mainte- 
nance Gateway (S-730) to request the stored logging of 
authentication failures (S-740) in HLR. Thus, the HLR 

25 logging regarding authentication failure report log shall 
be addressed as well to the Operation and Maintenance 
Gateway (S-750), so that they can be eventually for- 
warded to the FDS (S-760). Further, the FDS can ana- 
lyse the received secondary indicators for fraud in con- 

30 junction with applicable fraud criteria (8-530). Moreover, 
these secondary indicators will be used in the FDS in 
conjunction with some primary Indicators, as the 
number of call forwarding within a defined time Interval, 
to detect fraud situations such as SIM cloning. 

35 

Claims 

1 . A method for fraud detection in mobile telecommu- 
40 nications systems comprising the steps of: 

a) obtaining secondary fraud indicators from 
failures in user authentication procedures due 
to unsuccessful network authentications or un- 

45 successful user authentications; 

b) including said secondary fraud Indicators In 
the authentication failure report message (MAP 
AFR_req) sent from the Serving Environment 
(3G MSC/VLR, 3G SGSN) back to the Home 

50 Environment (HE HLR) in said authentication 

procedures, as new parameters of specific 
types for each of said indicators; and 

c) storing said messages In the Home Location 
Register (HLR) for further processing. 

55 

2. A method according to claim 1 , further comprising 
the step of fonA^arding an alamn message to a Fraud 
Detection System (FDS) entity through the Opera- 
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tion and Maintenance Gateway (OMG) when the 
number of authentication failures of an user ex- 
ceeds a predetemnined value. 

A nnethod according to claim 1 or 2, further compris- s 
ing the step of processing authentication failure re- 
port messages (AFR_req) In the fraud detection 
System (FDS) entity in conjunction with primary 
fraud indicators, for fraud detection purposes, hav- 
ing obtained said messages from the Home Loca- io 
tlon Register (HLR). 

A method according to any of the preceding claims, 
characterized In that said secondary fraud indica- 
tors includes the access type of the communication 
iri which the authentication procedure failed. 

A method according to claim 4, characterized in 
that said access type corresponds at least to a call, 
an emergency call, a location updating, a supple- 20 
mentary service procedure or a short message 
transfer. 

A method according to any of the preceding claims, 
characterized In that said secondary fraud indica- 2s 
tors Includes a re-attempt indicator indicating 
whether the authentication failure was produced In 
a nonnal authentication attempt or In a authentica- 
tion reattempt. 

30 

A method according to any of the preceding claims 
characterized In that said secondary fraud indica- 
tors Includes the Visitor Location Register (VLR) or 
the Serving GPRS Support Node (SGSN) address. 

35 

A method according to any of the preceding claims 
characterized in that said secondary fraud indica- 
tors are Included In extension container fields of 
said authentication failure report message (MAP 
AFR_req) instead of new parameters of specific 40 
types. 
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AuthenticationFailureReport OPERATION 


— Timer m 


ARGUMENT 




authenticationFailureReportArg 


AuthenticationFailureRq>ortArg 


RESULT 


authenticationFailureReportRes 


AuthenticationFailureReportRes 


— optional 


ERRORS { 




SystemFailurc, { 




UnexpectedDataValue, 




UnknownSubscriber } 





AuthenticationFailureReportArg : := SEQUENCE { 
imsi IMSI, 
failureCause FailureCause, 

extensionContainer ExtensionContainer OPTIONAL, 

...} 



FailureCause ::= ENUMERATED { 
wrongUserResponse (0) 
wrongNetworkSignature (1) } 



Fig. -4- 
Priop Art 
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failureCause 
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re-attempt 
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vlr-Number 
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